14th Annual PM Exam Prep Workshop

10 Tuesday Dec 2019

Posted by in Uncategorized

≈ Leave a comment

Tags

, , , ,

I’d like to invite all my blog readers to attend the 14th Annual Project Management Exam Prep Workshop. The class will be held from March 7th, 2020 to April 4th, 2020 (Saturday’s Only). Deadline for registering is Saturday, April 4th, 2020. Seats are going fast!

This intensive workshop addresses those core project management best practices, concepts, and processes that are necessary to initiate, plan, execute, monitor & control, and close projects. You will learn the best-practice processes required to communicate with your project team, procure the necessary materials for your project, assess risk/change and quality on your projects. This workshop is based on the Project Management Body of Knowledge (PMBOK®) 6th Edition.

The class will be held at DeVry University located at 8800 Governors Hill Dr. #100, Cincinnati, Ohio 45249. The cost of the class is:

  • Pre-Registration: $900 (11/1/2019 to 1/31/2020)
  • Regular Registration: $1,295 (2/1/2020 to 2/18/2020)

Your paid registration gets you a 1 yr. membership to the National Association of African American Human Resources, Ohio/Kentucky/Indiana Chapter. E-Learning will be available with your paid registration so if you are out of town you can still attend the workshop, at no extra cost to you!

If you have any questions, or are interested in registering, contact Gerald D. Smith, PMP, at 513-325-6513, use the toll-free number below, or send an email at gsmith@obosot.com. You can also go to OBOSOT.com or NAAAHRTraining.EventBrite.com to register!

Looking forward to seeing you at the next class.

Gerald D. Smith, PMP, MBA, CSP, CSM
Instructor
Toll Free: 855-416-2676

Phone: 513-325-6513
Email: gsmith@OBOSOT.com

Step 2: Agile Deployment

21 Thursday Mar 2019

Posted by in Agile, Leadership, project management

≈ Leave a comment

Tags

, ,

In a previous post I wrote about Step 1: Agile Transformation readiness. In this post, I will describe Step 2: Agile Deployment.

The goal of the Deployment Phase is to execute the agile approach and practices and help the team apply them to the pilot project. In Step 1, you created the agile methodology as part of your readiness strategy; in this step, you are now deploying it to a pilot team where they can begin using it. As part of your deployment process, ensure that the team is taught the new process and that there is a point-of-contact team members can engage to ask questions and resolve issues. Some would say this is the Agile Project Manager’s job, and they are right, except. However, when using a new process, it is wise to team the Agile Project Manager with a seasoned Agile Project Manager, who has led agile transformations before. This person must be able to communicate up and down the organizational hierarchy; talk effectively with the project managers, developers, testers, and managers; and demonstrate servant leadership and the Whole Team® philosophy. The Agile Project Manager, identified in Step One is typically that point-of-contact.

Deployment involves collaborating with stakeholders to carry out the following:

  1. Set up the agile planning tool. Excel can be used for the pilot, but as agile is scaled, it is recommended an enterprise agile project management software tool be purchased and used.
  2. Provide agile training. Do not underestimate the need for formal and informal training. It is recommended that the Agile Project Manager teach not only the science but the art of agile. Demonstration is an effective teaching tool, as people often learn best when observing others. Informal training is the coaching the Agile Project Manager provides while observing others in their day-to-day work environment.
  3. Deploy the agile methodology and practices. This is the methodology developed in Step One.
  4. Hold periodic meetings to ensure deployment is on track and directionally correct. It is strongly recommended that upper management be consulted on a regular basis so they know how the agile project team is progressing. Regular reporting can remove organizational impediments. Twice weekly meetings with the Agile Project Manager and a PMO lead can mitigate any misunderstandings, aid in needed course corrections, and just-in-time continuous improvement activities can be implemented quickly.

In many organizations that are implementing agile, tools are already being used for estimating and tracking progress. The purpose of this activity is to begin standardizing the tool-set and make sure the agile project teams are consistently using the same tools as they perform their work. In one company for which I consulted, the software development team stated they were using agile. The approved agile and collaborative tool suite consisted of:

  • A whiteboard
  • A Microsoft Excel™ spreadsheet
  • Microsoft Lync™ or LiveMeeting™
  • Microsoft Outlook™
  • Microsoft Word™
  • Mind Mapper™
  • Jira Greenhopper™
  • TitanPad™

Only the whiteboard and Microsoft Excel™ were being used, albeit sparingly and not effectively. The agile methodology developed in Step 1, instructed the pilot team to use Microsoft Excel™ and place a sprint burn-down chart on the white board, updated daily by the Agile Project Manager. The agile methodology also instructed the Agile Analyst (AA) to use Microsoft Excel™ as a product backlog, and a user story process was developed to aid in the management of the all the user stories. Now, some would argue the AA role should not be on an agile team; however, I have been in companies where the AA role is a specialized and entrenched role in the organization. Convincing the PMO management, that a team of software developers and testers will own requirements for an agile project will lead to a political battle that will doom your agile transformation. One strategy to use is to take what the IT department gives you and work with the roles (business analyst, project manager, developer, tester, architect, etc.) that are available and transform them into a true servants to each other.. Once they become more disciplined and the processes are intuitive,  the team begins to perform and the Agile Project Manager will see the individual roles disappear and the agile team’s  success will pave the way  to open  conversations about evolving the institutional roles to that or more agile-centric roles on an agile project ..

Providing agile training is not as simple as merely sending employees to agile classes. It involves much more. The employee should be taught the agile methodology that was agreed to and developed by the company in which he/she works for and the stakeholders have approved in Step One. Agile team members should be encouraged to use and increase their competence in the agile methodology. Only when they can prove competence and maturity in using the agile methodology should they be able to improve the methodology by bringing in new concepts. Some agile purists may not agree with that philosophy, but this author stands behind the notion that just because a person has been taught a “process” does not mean that person can successfully and consistently apply that process. The agile project team must be allowed to develop as a team, as the Tuckman Model suggests (Tuckman, 2012).

On the topic of software tools, the tools available in the industry are too numerous to count. I am not recommending one tool over another. But what I am recommending is that there is an agreed upon set of software tools that agile project  teams can use; that their use is monitored; and that continuous improvement of those tools is performed at regular intervals. Also, if an enterprise agile software tool is used, metrics should be captured to aid and give visibility to project team members and management. As long as the enterprise agile software tools add value to the agile project team and the creation of the new software product, use of any tool should be evaluated and agreed on for use by the agile project team.

I strongly recommend using the following process when selecting an agile enterprise software tool: Focus on People, Process, and Tools. Step 1 focuses on the People; steps 2 and 3 focus on the Process; only at step 4 should you have the conversation around tools.

People. The initial focus must be on people. The pilot team has to mature to a point where it can effectively use any agile software tools. I was leading the agile transformation of a young agile team that introduced an enterprise agile tool too early in the transformation. It created anarchy! I removed the use of the tool from the pilot team and we went to using a whiteboard and Microsoft Excel. The pilot team could not use those tools effectively. I realized that training was needed and sent the pilot team members to formal agile training and informal agile training on the new agile methodology. At the end of one release, the team had knocked off two weeks from their delivery cycle and during the retrospective, expressed excitement in planning out the release and sprints and seeing the iteration burn-down charts. What was interesting was what they listed for improvement in the upcoming release: that the Agile Project Manager stops asking them for their completed work that day; he was reminding them of a traditional project manager, command and control. At that point, they recognized the need for an enterprise agile software tool, where they can input their daily status and time and the Agile Project Manager can use it to ascertain project status and progress. Since they accepted ownership of each task, they also accepted the responsibility for reporting work on a task. The enterprise agile software tool was reintroduced to the team and they used it without hesitation. What was learned was three-fold: one, focus on the people aspect of agile transformation; two, ensure the pilot project team members are trained on the new agile methodology; and three, let the team develop and solve their own problems. As the leader of the transformation, you can fall into the trap of telling the team what to use (the tool) instead of asking the team what they need (servant leadership) and supporting them in their progression toward agility.

Process. Once the pilot project team has been trained and a pilot project has been selected, deploy the agile methodology and practices to the team and monitor progress. This can be performed by the Agile Project Manager. This is where organization change management concepts can be leveraged. Organizational change is defined as a difference in form, quality, or state over time in an organizational entity (Van de Ven & Poole, 1995, p.512). The entity may be an individual’s job, a work group, an organizational sub-unit, the overall organization, or its relationships with other organizations. In this case, it is the new agile methodology. Change can be measured by observing the agile methodology over two or more points in time on a set of characteristics and then observing the differences in these characteristics over time. If the difference is noticeable, we can say that the organizational entity has changed (Van de Ven & Sun, 2011). Much of the voluminous literature on organizational change focuses on two questions about this difference:

1) How and what produced it?

2) How might it be managed in sustainable and constructive directions over time?

Question 1 will be addressed in Chapter 10. Question 2 is answered in the following context: when a new process is introduced to employees, they tend to have problems implementing it and always have questions. The Agile Project Manager can be leveraged as the point-of-contact to answer those questions and model the use of certain agile techniques and principles. There should be an agile transformation governance team consisting of the person funding the transformation in addition to senior members of the transformation pilot project. The primary purposes of this governance team is to collect feedback on the use of the agile methodology; make suggestions for changes to the methodology; and communicate with middle- and upper management on the agile transformation’s progress.

This leads us to holding periodic meetings to ensure deployment is on track and directionally correct. Ensuring you have an executive champion will not guarantee that an agile transformation will be successful, but can increase the odds. While leading an agile transformation, you must keep the executive sponsor and his orher stakeholders informed of progress, challenges, risks, and successes. It is also recommended that you spend real dollars instead of implementing an agile transformation off the side of your desk. More attention is given to projects by executives where real capital dollars are being spent than to projects using “invisible” expense dollars. This will also give you and your transformation team the support it needs to remove constraints, obstacles, and issues that can consume your agile transformation initiative if left unattended.

Tools. Lastly, enterprise tools should then be introduced to the agile project team after the Agile Project Manager has address the People and Processes part of the triangle. Agile software tools can be an effective and efficient way to collect metrics, proactively anticipate risks, and provide just-in-time access for upper management on how the pilot project is progressing.

Agile Transformation Readiness

31 Wednesday Oct 2018

Posted by in Agile, Leadership, Waterfall/Traditional

≈ Leave a comment

In a previous post I wrote about starting an agile [project and software development] transformation. I listed the four steps to the transformation. This blog posting discusses step 1, Agile Transformation Readiness

The goal of the Readiness Phase of an agile adoption is to understand the current state of the organization and stakeholders, set the expectations for change, and establish an overall strategy and plan for the engagement. Essentially, this is the time when you identify how agile can work in your company. Too often, companies send employees to training and expect them to return ready to apply the newly-learned skills. Most training only teaches the science of agile or, put another way, what needs to be accomplished. The classes often fall short in teaching the art of applying those skills within a company. Readiness involves collaborating with stakeholders to do the following:

  1. Identify an agile coach: Who will guide, mentor, and lead the transformation?
  2. Establish a strategy and roadmap for implementing agile: What parts of the company will start the agile transformation journey? Project management office, software development, infrastructure, corporate security, quality assurance, data modeling, architecture, or all of the above? And, what is the approach for implementing the transformation? In Figure 1, a typical IT department is made up of, at minimal, two but also three areas; Discovery, Delivery, and Operations. Discovery is where research and development are housed to identify a new product or service; Delivery is where the projects are initiated to build the new product or service; and Operations is where the new product or service is maintained during its life-cycle. The Agile Project Manager must determine in what area the agile transformation will begin.

ITOrg

Figure 1 – A Typical IT Ecosystem

  1. Establish the agile framework and practices methodology: What framework will be used to guide the agile team? DiPD™ Scrum, DSDM, Extreme Programming Scaled Agile Framework Enterprise (SAFe); Who will train the team? How will continuous improvement be performed? Who will govern the process to ensure that it is being used correctly and effectively? Has it been approved by the collaborators?
  2. Determine suitability of projects using the Decision Matrix: Will all projects begin using the new agile framework? Will skunkworks projects use the new agile framework? Skunkwork projects, according to Webopedia, are typically small and loosely structured group of people who research and develop a project for the sake of innovation. A skunkwork project often operates independent of a company’s normal research and development operations, or project management framework, and therefore often is subject to limitations in resources. Skunkworks projects often are undertaken in secret with the understanding that if the development is successful then the product will be designed later according to the usual project management process. Will there be absolutes for a project to begin using the new agile framework? How will the Agile Project Manager decide if a project can use the new agile framework?
  3. Establish periodic progress meetings: Is there a need to ensure that middle managers and above are kept abreast of the agile transformation progress?
  4. Assess engineering practices and agile mindset of the organization: Have agile practices been adopted by the group but are being ignored?
  5. Focus on agile mindset and cultural shift: How will the new agile framework be rolled out to the larger body of IT and business employees? Who will be responsible for organizational change management?

This typically takes anywhere from 4 to 6 months, depending on how complex, siloed, and political your organization is. An Agile Project Manager should be responsible in leading the agile transformation within a company. It is recommended the Agile Project Manager be interviewed and chosen by the transformation team. Once selected, the Agile Project Manager can facilitate the discussions to develop the strategy and roadmap that will aid your company’s agile project  teams in determining how long the transformation will take, how many phases it will contain, who will be involved, and when the transformation will conclude. Establishing a readiness roadmap for using agile will aid in the identification of the parameters an agile project  team in your company will use to ensure that they are consistently applied, can be measured, and identify training needs.

Determining the suitability of projects will aid in selecting the right project. A decision matrix can be used to select the appropriate agile project for use in a pilot. Risk, high-level requirements, and other criteria can be added to the matrix so that the agile transformation team can select the best project for the pilot. Too often, I hear that “all” projects can use agile. That may seem true, but what typically is missing is the following:

  1. The project team is not experienced in agile and they select the wrong project and fail in their delivery.
  2. The project team is not mature enough to work collaboratively and they fail to take ownership of tasks, fail to measure their progress, and fail to use the company approved agile practices needed to successfully deliver the project;
  3. The project team’s management does not use servant leadership in supporting the agile project team and resort to using command and control techniques that lead the team back to a traditional project management approach, causing the team to fail in its delivery.

Assessing engineering practices and agile mindset of the transformation team and is one of the most overlooked aspects of an agile transformation. Establish periodic meetings to ensure that upper and middle management are presented with regular updates on how the agile transformation is proceeding. Investigate the agile software engineering practices that are being used currently in your company; these can be integrated into the new agile framework and will reduce the amount of resistance you experience in introducing the new agile concepts. Make sure the agile project team(s) responsible for implementing the new agile framework are bought-in to the concept. Nothing can affect a project team more than lack of team commitment and buy-in.

Finally, understand that anytime you introduce a new concept into a bureaucratic and highly politicized organization, organization change management (OCM) is needed. OCM is a methodology for managing the effect of new business processes, changes in organizational structure, or cultural changes within an enterprise. Simply put, OCM addresses the people side of change management (Rouse, 2012). Rouse says that a systematic approach to OCM is beneficial when change requires people throughout a company to learn new behaviors and skills. By formally setting expectations, employing tools to improve communication and proactively seeking ways to reduce misinformation, stakeholders are more likely to buy into a change initially and remain committed to the change throughout any discomfort associated with it.

Starting an Agile Transformation

30 Tuesday Oct 2018

Posted by in Agile, project management

≈ Leave a comment

Tags

If you begin an agile transformation without a plan, you are merely wishing for agility to happen in your company. Planning is key to success. When beginning an agile transformation, the Agile Project Manager must list the needs of the company,  the risks, and the constraints. In one Fortune 500 company I worked in while leading an agile transformation, I listed the needs as being the following (in order of priority):

  • Projects must be completed in shorter durations
  • Changes to project scope must be accepted and not rejected
  • Project deliverables must meet and exceed customer expectations

The following are a few of the constraints that exists in many companies that are attempting to move toward agility:

  • Resources will not be 100 percent dedicated to a single project;
  • The environment is a tiered organization, meaning software development, the project management office PMO, and infrastructure, or shared services, are in separate silos;
  • Projects have to go through an extensive capitalization and tollgate process before funds are allocated;
  • Resource managers and project managers use command-and control techniques to manage projects.

Once the needs, risks, and constraints have been identified, the Agile Transformist needs to develop a plan that will remove, minimize, or defer them so that the Agile project  Manager can create momentum and buy-in for the move toward agility. The plan I’ve formulated is the following:

Step 1: Determine the team’s readiness for agile

Step 2: Deploy the agile process to the organization

Step 3: Determine how to support the agile process

Step 4: Provide consistent coaching for all involved in the agile transformation

I’ll go through each step in subsequent posts.

Delivery, Delivery, Delivery

03 Wednesday Oct 2018

Posted by in Agile, project management, Waterfall/Traditional

≈ Leave a comment

As a project management professional and a teacher of project management (PM)  I always state the following to other practitioners and students, “Have a project management utility belt so that you can pull out a PM tool that can be used in any situation.” This edition of OBOSOT Quarterly™ represents the epitome of that statement. Having a firm understanding of what methodology to use, when to use it, and how much flexibility to allow will aid your ability to successfully lead and manage projects in any industry. While each methodology has benefits not one methodology can be used in all situations. Having the ability to mix-n-match methodologies into a ’hybrid’ approach may increase your probability of project success. While the success rate of projects has increased from 16.2% to 29-33% since 1995 (see https://speedandfunction.com/look-25-years-software-projects-can-learn/), the overwhelming majority of projects continue to show signs of challenge or failure. It isn’t what PM methodology you use nor what are the benefits of one methodology over the other; it continues and always will be did you delivery the project, on budget, on scope, under budget and achieving customer satisfaction?    In this age of rapid change, companies are introducing projects into their pipeline at an accelerating rate; project delivery will grow in importance and become the difference between a company staying relevant in the 21st century or becoming irrelevant, or worse, non-existent. Knowledge in project management methodologies is a job requirement for PMs.

Agnostic Project Managers

01 Monday Oct 2018

Posted by in Agile, project management, Waterfall/Traditional

≈ Leave a comment

I’ve been a project management professional for over 20 years and I’ve seen a lot of changes in the PM industry. Agile is by far the most encompassing change I’ve seen. It requires a project manager to evolve their ideology in how they not only manage but also lead a project. Being proficient in one methodology and/or framework is in the past; being agnostic is the future. As project managers we must always have one foot in the future; while we navigate the present all while being customer focused.

Path to Agility 2018 – Central Ohio Agile Association (COHAA), Columbus, Ohio, May 23-24, 2018

07 Thursday Jun 2018

Posted by in Agile, Leadership, project management

≈ Leave a comment

The premier agile conference in the State of Ohio; that is a powerful statement! It doesn’t hurt that Ken Schwaber, one of the original signers of the Agile Manifesto has a home and business in Columbus, Ohio, the city that is hosting the conference. Now, for the commercial: The Path to Agility conference was developed to further COHAA’s mission to inspire creativity and innovation in the delivery of value.  COHAA has engaged national and regional Agile thought leaders to provide session content focused on a mix of business, technical, and/or management topics. Whether you are well along the path or just starting out, this conference will help guide you in the right direction. My synopsis of some of the speakers is below.

One of the keynote addresses was provided by April Wensel, a veteran software engineer and technical leader whose varied career spans such fields as education (Zoodles), research (User Testing, Carnegie Institution at Stanford), healthcare (Cognoa), and entertainment (Sony, Playdom). She has also mentored and led workshops with diversity-focused organizations like Hackbright Academy and Black Girls Code. She spoke about compassionate coding; that software projects are failing, not because of technical reasons but due to people reasons. She spoke about awakening compassion at your workspaces, know your key values, and remember the 3 steps: slow down, empathize, and remove suffering while you do your IT jobs. In short, understand the ‘Why’ in ‘What’ you do and make sure it aligns with your personal values.

The next speaker was Allen Bennett, scrum coach with Tata Consultancy. He spoke about the 6 views of the agile manager, which are: empower teams, energize people, align constraints, develop competence, grow everything, and improve competence. He also discussed the 7 levels of delegation: tell, sell, consult, agree: make decision with the team, advise: influence the decision, inquire: ask for feedback, and delegate: let the team work it out. His emphasis was on the responsibility of the agile manger as it relates to overall agile team development. The agile manager must learn to trust, empower, and delegate responsibility to the team so the team can grow beyond its limits.

A former colleague of mine, Dan Rice, discussed agile and continuous delivery. What I liked about his presentation was one, it wasn’t a sales pitch; and two, it was framed very clearly on what continuous delivery is, why a holistic and principled approach is needed to ensure that the organization or department is going in the right direction with their software development and deployments. He gave a story about how at Rally Dev: a customer raised a defect; that defect was replicated as an incident in the development tool the Rally developers were using; a scum team with available capacity, picked up the defect, validated it, and pulled it into the sprint backlog; remediated the defect and checked it in to a code repository; automated unit test scripts were ran against it and passed; once passed, the code was automatically checked into the test environment where automated test scripts were ran against it and passed; then the code was automatically checked into the staging environment where automated test scripts were ran against it with dependent services and APIs; it passed. The fixed code was deployed to production where automated production test scripts were ran against it; passed, and the ‘bad’ code was removed from the production environment, replaced with the ‘good’ code. This occurred in 45 minutes…WOW! That’s what I want my continuous environment to resemble when it grows up. One major constraint with agile software development teams is the missing continuous deployment architecture component that can take advantage of the quick remediation turnaround performed by the agile team. Until that is resolved, companies will continue to have agile-fall frameworks.

My dear friend and colleague at Cohesion, IT Consulting, Sam O’Brien, discussed taking your team to new heights using agile. At its heart, she discussed trusting and respecting the team to perform in ways that they never could have imagined. Be a leader and not a manager. Listen with your eyes, not just with your ears. The agile team needs to embrace the concept of successful failure and encourage new ideas and creative thinking. Her talk focused on whole team development that both the product owner, scrum master, and agile project manager should be aware of when they collaborate with the entire agile team to achieve successful and predictable delivery.

An agile coach and even a scrum master should always guide the team using the agile manifesto as a guide while also understanding, clearly, the environment you and the team are residing in. Scrum software development, or project management, is not structured to be ‘by-the-book’. By its very nature, Scrum is a constant journey of inspection and adaptation. But there comes a time when it’s a good idea for an Agile team (mature or not) to take a step back to review and relearn the foundation principles and practices of Scrum. In other words, have a team “reset” (Nennessy, 2012). A good coach understands presence, be in the moment with the individual, team, or client. Coach the individual, not the problem. If you coach the person they will solve their own problem. Mentoring is coaching the individual but also offering advice, providing resources , telling stories about one’s experience, teaching of models, (selecting from options) (Adkins, 2015).

I hope this provides you with insight into my experiences at the conference. Your comments are welcomed.

Team Productivity Gains with DiPD

21 Monday May 2018

Posted by in Agile, Leadership, project management, Waterfall/Traditional

≈ Leave a comment

Tags

, ,

In order for a company to truly obtain the benefits of Disciplined iterative Project Delivery (DiPD™), the company must allow for a level of maturity to develop through the disciplined use the framework’s best practices. Understand, the resources may have little to no previous disciplined use of an iterative approach. It is recommended that management first determines which projects show the DiPD™ characteristics. A decision matrix should be used to assess whether using DiPD™ will be successful. This is a valuable tool because it formalizes the decision-making process and empowers management and agile project team members to determine the risks and constraints that must be mitigated to ensure the project has the best opportunities for agile success. Too often it is believed that all projects can be iterated, or use agile, while little effort is taken to understand the organizational constraints that may inhibit the effective use of agile tenets and best practices. Using the decision matrix, the organizational risks and constraints can be brought to the forefront and agile project management can iteratively transition management and resources toward agility. This approach also enables management to make an informed decision on which project delivery method to use: traditional or DiPD™. Additionally, the use of the decision matrix begins the risk management process advocated in the Project Management Body of Knowledge™. In this process, the resources management reviews the results of the decision matrix to determine the necessary risk mitigation strategies and triggers, and to select a pilot project. Once a pilot project has been through the decision matrix, the resources assigned to the agile project begin using DiPD™ and are coached using the Whole Team™ approach. This Whole Team™ approach should be used from project to project to achieve the continuous improvement needed to deliver projects Better, Faster, and Cheaper™. Whole Team™ also holds the entire agile resources accountable since every agile resource self-selects on the tasks needed to complete the iteration/sprint in a transparent way. Once these activities are performed, the benefits the performing organization is attempting to achieve will fall in line while improving overall customer satisfaction. In addition to supporting DiPD™, management support is needed to continuously improve the project processes that agile resources are using  based upon the department and/or company’s organizational maturity in agile. Figure 1 depicts an agile maturity model that the project management office can use to gauge a department/company’s current state and plan for its future state.

The department/company should employ servant leadership concepts and create an environment that doesn’t hinder employees from doing their work. It should be noted that agile project teams may experience less productivity as they are initially staffed and coached using the Whole Team™ process and DiPD™ framework. It is recommended the agile project manager understand the Tuckerman’s Group Development Model (forming, storming, norming, performing, and adjourning) as they implement Whole Team™. Once the resources assigned to an agile project reach the performing stage of team development, team collaboration, and an established cadence, will be set and at its best.

AgileMaturityModel

Evolve or Be Left Behind

16 Wednesday May 2018

Posted by in Agile, Leadership, Waterfall/Traditional

≈ Leave a comment

I continue to find it disheartening when I hear the following words from project managers in the field, “We don’t do agile here” or “All we do is waterfall, agile will never work here.” It’s as if my project management colleagues have not been paying attention to the ever changing business environment. They seem to believe that we’re fighting a war: the waterfall proponents are on the right side and the agile proponents on the wrong site. This is not a battle of good vs evil; not even a view that waterfall is good and agile is bad. This has moved from being a project/software management process to a business model process. Changes in the business world are occurring at a record pace. What once worked before, will not work in the future. Just look at Sears, Toys R’Us, GE, P&G, etc. In order to survive, companies must transform to digital enterprises, and within those companies, PMOs must incorporate capabilities that lend themselves in support of digital enterprises. A recent study uncovered that CEOs are aiming for a 10% annual growth rate in digital revenues (Gartner, 2017). One CEO stated “Becoming digital means more than simply changing products and services. It means changing the way we work. We cannot transform our business model unless were willing to transform our operating model (CEO Fortune 500 manufacturer).” How is a company going to achieve 10% annual growth by ‘ONLY’ delivering projects using a waterfall methodology? By the time the project is complete, the product the project is delivering may not be viable.

Even PMI has embraced a Talent Triangle™ model for its members; focusing on strategic and business management along with leadership. No longer is it business as usual to check all the PMBOK™ boxes as it relates to IPECC (PMPs know what that is). A project management professional must assist their organization in transformative project management; and that means adopting and incorporating iterative and even agile best practices into the way you manage your project. Don’t get me wrong, there are projects where waterfall works best; but an agile framework, incorporated into a waterfall methodology, may increase your delivery rate. It is well documented that using a hybrid project management model, leads to shorter development cycles, higher customer satisfaction, lower bug rates, and quicker adaptation to rapidly changing business requirements have been reported (Cho, 2009).

So, the next time you hear a colleague say “We don’t do agile here” or “All we do is waterfall, agile will never work here.” Kindly say the following, either evolve or be left behind!

Why is Hybrid Agile Such a Bad Thing? The Secret Is That It Really Isn’t!

20 Monday Nov 2017

Posted by in Uncategorized

≈ Leave a comment

Tags

, , , , ,

With the movement toward agile software development and agile project management; and with all the training available from certified scrum trainers, agile certified practitioners, and product owner, and with the move of software development to near-shore and off-shore location; why isn’t there any training on how to transition a scrum team from one location to another and more importantly, why does a hybrid agile approach seem so bad? The perception is that if you are not using “pure” agile then you are prone to fail in your attempt to utilize agile to achieve all of its benefits.

But there are times in organizations that leadership decides to go in a direction that is in direct opposition to the agile manifesto and the twelve agile principles. What is a certified [agile] project manager to do? Complain about the lack of “pure” agile commitment? Become a martyr and work against the interests of leadership? No, what a certified [agile] project manager would do is find a way to incorporate the best practices of the project management with the twelve principles of the agile manifesto in way that leads to team growth, increased productivity, and more efficient project delivery in an iterative way.

The agile team decided to use scrum as a framework but with caveats. We had to incorporate approval gates and work with a project management office where I was required to provide status updates, manage change, and obtain approval for budget and release management. This resulted in a hybrid agile approach called DiPD®, Disciplined iterative Project Delivery®. The iterative framework is typical of any scrum development workflow with a few exceptions. One, I did not release at the end of every sprint; two, I needed approval to move from project intake to release; and three, I used documentation.

Starting with the product backlog, also known as a work item list. It contains uniquely ranked stack of user stories so the team can focus on delivering valuable functionality. The ranking of the user stories aids the business stakeholders to decide which functionality is more valuable than others (e.g. MVP1, MVP2, etc). Having MVP2 user stories in the backlog that are not being worked on is acceptable and means the team hasn’t gotten to them yet. User story dependency is included so the team doesn’t work on a user story too soon; this prevents work disruption.

Project Scoping Current State (Business Ideas)

This is important to our team for the following reasons:

  • First time our team is made aware of the entire project.
  • This is formal notice given to our team to proceed with maturing the Project.
  • While change requests have the business needs defined, they do not include all the assets necessary to build out the solution.
  • This introduces the project to the larger team so they can become aware.
  • This identifies dependence among user stories which aids the Product Owner in aligning the Project for future sprints and releases.
  • It provides a high-level estimate of effort of business decision can be made.
  • This is the formal handoff from our team to our client of the analysis performed.
  • Business has the opportunity to resubmit or stop the project.
  • This formalizes the project into executable work for future delivery.

This is where our team provides the estimates, acceptance criteria, and user story dependency back to the Product Owner, and where our client can approve / reject / hold the change request.

 Epic and User Story Maturity (Product Backlog)

This is important to our team for the following reasons:

  • The business analyst works on only approved projects.
  • The Scrum Master can provide awareness of the approved user stories with each of the teams.
  • The Scrum team members have vetted the general requirements and posted needed questions/clarifications ultimately back to the Product Owner for maturity.
  • The content of user stories is complete; all questions/clarifications have been made; and all acceptance criteria are adequate for development and testing to successfully deliver.
  • The Scrum team members understands how to approach the testing of the user stories’ functional and non-functional aspects.

This is where our product backlog is built with a goal of keeping it healthy so work can be continually ‘pushed’ to the team.

 Acceptance (Sprint Backlog)

This is important to our team for the following reasons:

  • Allows our team to fill out sprint capacity.
  • Allows our team proactively make adjustments to sprint work due to changes in resource availability or prioritization.
  • Sprint and release placement aids our client in knowing when an approved project are planned for release.
  • Our client can notify their Partners accordingly.
  • Their Partners can begin assigning resources UAT.
  • Our team is able to ready the approved project and user stories for sprint planning activities.
  • Our team is able to provide a sprint roadmap to the team.
  • Our team is able to provide a release roadmap to LE.
  • Our client is able to realign partner priorities and communicate expectations.

Our client and our team are able to baseline the sprint

Approval Gates (PMO)

Agile, by its nature does not have approval gates. However, in all of the companies I have worked, I have never been able to deploy code to a production environment without having to obtain some level of approval. So in reality, there is an implied approval that has to be obtained before moving forward with a deployment. There are mandatory approval gates my team must adhere to as work moves from idea to working code in a production environment.

This is important to our team for the following reasons:

Gate 1: Defined business ideas

  • Our client is able to filters unviable projects from coming to our team.

Gate 2: Estimation approval

  • Our client determines if business case is relevant based on estimates provided.

Gate 3: Backlog maturity

  • Our client reviews functional solution for MVP and determines if the solution is supporting business need.
    • Our client needs to understand what they are signing off on so it meets the business need preventing rework and future story creation.
    • Our client needs to plan UAT, engaging their partners, aligning external parties around the functionality that is being defined.

Gate 4: Sprint planning

  • Our client defines the priority of work among all projects.

Gate 5: Sprint demo

  • Our team and our client signoff on expected work, the sprint increment, in accordance to quality requirements.

Gate 6: Our client provides our team with release approval.

Both our team and client are assured that modifications work as expected in the end-to-end environment and decides whether work will be released

The Results

There is a lot to like about the DiPD® model. For starters, I was able to increase scheduled release frequency, year over year by 45%. I was able to increase scheduled out of cycle releases year over year by 300%. I was able to add and train a second scrum team using the DiPD® framework and deliver a digital download platform that had failed in a larger company, in 7 months. And finally, I was able to successfully transition development from the U.S. to Bangalore, India in 4 months. There is still a lot of work to do but the hybrid framework is working for my team and my client. And remember, quality is not what you or I deem it is; quality is what the customer deems it is. Specifically, when a product of service completely meets a customer’s need, quality is delivered (PMBOK®, 5th Ed.).

To close, using a hybrid agile software or project management approach isn’t a bad thing. With the challenges facing companies today, following any framework to the letter is a huge risk. You need to incorporate the best practices of project management with the twelve principles of the agile manifesto in way that leads to team growth, increased productivity, and more efficient project delivery in an iterative way. Move to pendulum from bureaucracy to agility…iteratively™.